1. Field of the Invention
The present invention relates generally to the field of computer software, and more particularly to a multi-lingual tag extension mechanism suitable for use with JAVASERVER computer software Pages.
2. Description of the Related Art
JAVA programming language is expressly designed for use in the distributed environment of the Internet. It was designed to have the “look and feel” of the C++ language, but it is simpler to use than C++ and enforces an object-oriented programming model. JAVA programming language can be used to create complete applications that may run on a single computer or be distributed among servers and clients in a network. It can also be used to build a small application module or applet for use as part of a Webpage. Applets make it possible for a Web page user to interact with the page. JAVASERVER computer software Pages is the JAVA programming language platform technology for building applications containing dynamic Web content such as HTML, DHTML, XHTML, and XML. A JAVASERVER computer software Page (JSP) is a text-based document that describes how to process a request to create a response. The description inter-mixes template data with some dynamic actions, taking advantage of the capabilities of the JAVA programming language platform. The template data is commonly fragments of a structured document (HTML, DHTML, XHTML or XML), and the dynamic actions can be described with scripting elements and/or server-side actiontags.
A simple example of a JSP page is shown in FIG. 2. The example shows the response page, which is intended to be a short list of the day of the month and year, at the moment the request is received by the server. The page itself contains some fixed template text, and JSP elements that are shown underlined in the figure. The underlined actions are executed on the server side. When a client makes a request, such as an HTTP request, a request object requests a response from the JAVASERVER computer software container. The first element creates a JAVA BEAN computer program named clock, of type calendar.jspCalendar. The next two elements use the Bean to display some of its properties (i.e. month and year). The output is sent to a response object which sends a response back to the client.
A JSP page is executed by a JSP container, which is installed on a Web server, or on a Web enabled application server. The JSP container delivers requests from a client to a JSP page and responses from the JSP page to the client. JSP pages may be implemented using a JSP translation or compilation phase that is performed only once, followed by a request processing phase that is performed once per request. The translation phase creates a JSP page implementation class that implements a servlet interface.
Typically, a JSP page contains declarations, fixed template data, action instances that may be nested, and scripting elements. When a request is delivered to a JSP page, all these components are used to create a response object that is then returned to the client. As with standard Web pages, JSP pages may contain “tags.” In order to facilitate the construction of Web pages, standard page formatting codes, known as tags, are provided. A tag is a textual element within a document that provides instructions for formatting or other actions. For example, World Wide Web documents are set up using HTML (Hyper-Text Mark-up Language) tags which serve various functions such as controlling the styling of text and placement of graphic elements, and also providing links to interactive programs and scripts.
In standard implementations, a JSP page is translated into JAVA programming language code that runs on a server. The transformation from the JSP page into JAVA programming language code is done once, when the page is first accessed. The JAVA programming language code running on the server is activated when a request is received. In order to create a response object, certain data is passed verbatim to the response, and some actions are executed on the server side. Some of these actions are explicitly spelled out in the JSP page, and other actions are described by the semantics of the text. Thus, there are three types of code: verbatim code, scripting code from the JSP page, and code which has to be defined by the tag library. As used herein, “tags” in the JSP context will be referred to as “actions.”
Ideally, a tag mechanism employed in a JSP page system would allow for actions to be defined in standard libraries. This would allow third parties to provide new actions as part of their JSP authoring tools. For example, as shown in FIG. 3, a JSP page author may use a JSP specification-compliant authoring tool to create a Web page. The vendor of the authoring tool can provide new actions via a JSP tag library, such as a tag library that supports chat room functionality. The page can then be deployed into any JSP-compliant container, such as a Web browser. The Web browser uses the same tag library information in order to run the Web page, including the desired chat room functions.
In other words, if a standard JSP tag mechanism is properly defined, vendors of tag libraries can use the standard specification to create tag libraries that are compliant with the JSP environment. Also, vendors of authoring tools can create authoring tools (and scripting languages) compliant with the specification, and vendors of Web browsers can create JSP compliant Web browsers. A Web page author can then choose the best tag library and the best authoring tool available for creating the desired Web pages. Two different Web browsers may support scripting in a completely different manner, but the same tag libraries must be supported by both in order to run the Web page.
Therefore, in order to provide the desired functionality, the JSP specification needs to define the semantics of an extensible tag mechanism that can support the following constraints:
the tag mechanism can be implemented with minimal assumptions about the page implementation (i.e. only “callability” from the page into the extension should be assumed);
minimal constraints on the page translation process are imposed;
supports tag body evaluation;
portable—a tag described in a tag library must be usable in any JSP container;
simple—a mechanism that is accessible and easy to use, both by users of the tags (JSP authors, creators of JSP authoring tools) and by authors of tags;
expressive—enable a wide range of actions; in particular:                nested actions        scripting elements inside the tag body        refer to scripting variables, and create and update scripting variables; and        
usable from different scripting languages, not just JAVA programming language.
The more powerful the tag library mechanism, however, the more difficult it is to satisfy these constraints.
Currently available commercial products do not provide the desired functionality. For example, the COLDFUSION Web application sever CFX mechanism does not provide for body evaluations. Compilation-based mechanisms, such as the LIVESOFTWARE JRUN Web application sever mechanism, make significant assumptions about the page implementation details. Also, pure translation-based methods, like XSLT need to make assumptions about the scripting language.
One prior art approach is to define the semantics of each tag through a transformation into a scripting language. The problem with this approach, however, is that the tag library author does not know the scripting language that will be used, so it is very difficult to define the transformation. A second approach relies on the concept of a “closure.” In an evaluation system, a closure is a data structure that holds an expression and an environment of variable bindings in which that expression is to be evaluated. The variables may be local or global. Closures are used to represent unevaluated expressions when implementing functional programming languages with lazy evaluation.
FIG. 4 illustrates how a tag can be translated into a closure. The idea of a closure is to encapsulate a tag “body” into a software object called a closure. A closure is a procedure with some context, such that the object can evaluate itself. The closure is instantiated and passed to an implementation of the tag library. The tag library can then execute the action and determine how many times to invoke the body if, for example, the body contains a loop.
During the translation process, a tag “foo” in a JSP page (FIG. 4) is transformed into a closure. An Implementation Class (type servlet) is created, with the code associated with the “Body” of the tag corresponding to the closure (i.e. the underlined code). When a request is received, an instance of the closure is passed to the tag library. The tag library then executes the action, using a single “doIt ( )” method. The main advantage of using a closure to perform the tag action is that no special knowledge is needed in order to execute the closure. Specifically, no knowledge is required of how variables are accessed, since the closure contains the necessary context. A closure is difficult to create, however, since it is difficult to provide the requisite context. In fact, the JAVA programming language does not support the use of closures.
In view of the foregoing, there is a need for an extensible tag mechanism that can provide the desired functionality in JAVA programming language programming environment, regardless of the scripting language used to develop the JSP page (i.e. multi-lingual), and which does not use a standard closure.